A presence service is a service to exchange presence information Items indicating states, i.e., presence of human beings, articles or items, and services. The IETF RFC2778 describes a basic architecture of a presence service. Clients using the presence service are classified into two types of clients: presentities (on an information delivery side) such as users providing presence information and watchers (on an information receiver side) observing the presence information. The word presentities is a combination of words “presence” and “entity” and was first introduced in RFC 2778. Originally, it was defined as a logical entity which provides presence information and usually refers to a human. Although a presentity is most commonly a reference for a person, it may represent a role such as “help desk” or a resource such as “conference room #27.” Presentities are generally referenced by distinguished names, such as “sip:joe.bloggs@example.com” or by phone numbers like “tel:+12345678”. In this case presence information describes the availability, proximity, activity level, status, operating state, capabilities, and/or willingness of a presentity to communicate via set of communication services. For example, users of the instant messenger ICQ (“I seek you”) are presentities, and their presence information is ICQ user status (online, offline, away, etc.). Although there may be multiple presence sources associated with a single presentity, for ease of description here, only the term presentity is used and includes the logical entity and/or one or more presence sources associated with that logical entity.
The presence service receives the presence information from presentities and then delivers that presence information to watchers. A watcher can keep track of presentities. The most common use of presence today is a status indicator displayed on most instant messaging clients, typically in form of an easy to convey graphic symbol and a list of text descriptions of each of the status. Commonly used status that offer extended information on the user's availability are “free for chat”, “away”, “do not disturb”, and “out to lunch”, and exist in many variations across different modern instant messaging clients. User selectable richer information such as user mood, location, and free text status may also be available. Presence is different from traditional on-hook telephone status in that it deals with the availability of the user not just with the availability of the user device and its required technical properties.
The presentities publish their presence information to a presence server, which composes a notification to the watcher. The presence server handles publications by refreshing presence information, replacing existing presence information with newly published presence information, or removing presence information for a given presentity. The notification typically contains the information from all the presentities that the watcher has subscribed to. When any of the presentities change their presence state, they again publish their new presence information to the presence server, which in turn notifies the watcher with the new presence information.
A protocol that is used for presence is the Session Initiation Protocol (SIP). In RFC3261 describing the SIP protocol, the publications sent from the presentity to the watcher are in the form of SIP PUBLISH messages, and the notifications sent from the presence server to the watcher is in the form of SIP NOTIFY messages. A high level overview of a presence system 10 and signaling is seen in FIG. 1. Multiple users 12 labeled 1-5 send SIP PUBLISH messages to the presence server 14. The presence server 14 processes those messages and sends SIP NOTIFY messages to the watcher 16 based on the watcher's subscription information provided to the presence server 14 via a SIP SUBSCRIBE message.
Although presence applications have been used over the fixed internet for a number of years, presence applications are applicable to cellular and other wireless networks as well. A significant problem with applying presence over cellular networks is the potentially huge amount of signaling associated with presence messages that could easily drain the cellular system of capacity. Studies by the assignee of this application regarding the impact of presence traffic on cellular capacity in GSM/EDGE suggest that even a presence application which is moderate in signaling may reduce cellular system capacity by 10-15 percent for Voice over IP (VoIP) over GSM/EDGE. With increased signaling, the capacity reduction can easily reach unacceptable levels.
There have been efforts to limit the presence traffic are under development, but they have not been sufficient to consistently keep the traffic at a reasonable level and to provide the desired flexibility and selectivity. For example, when presence applications become available in mobile terminals, new types of presence information will likely become interesting and will be need to be supported. Geographical location is particularly meaningful presence information for mobile terminals because the presentities associated with those mobile communications terminals can move during a session, in contrast for example, to presentities connected via the fixed position Internet.
One possibility for obtaining geographical information is to use a GPS device in the presentities's communications terminal or user equipment, e.g., cell phone, PDA, lap top computer, etc. When the GPS coordinates indicate that the communications terminal has moved, the new coordinates are published to the presence server which distributes that information to the watchers. Unless the communications terminal itself limits these new coordinates publications, this approach will result in a tremendous amount of signaling. For example, if the terminal is located in a moving car, then the coordinate update publications will be generated more or less continuously. Supporting this kind of signaling in wireless networks that have limited bandwidth capacity is a significant problem.
To illustrate these difficulties in a SIP messaging context, the presence update signaling can be divided into two phases. The first phase is the SIP PUBLISH messages sent from the presentity to the presence server, and the second phase is the SIP NOTIFY sent from the presence server to the watcher. The signaling in the first phase does not allow an efficient way for the presence server to limit the presence update signaling traffic. One possibility is for the presence server to respond to a PUBLISH message with a service unavailable message with a “Retry-after” header field indicating the time that the presentity must wait until the presentity can send a new PUBLISH message. But this does not guarantee that the presentity will not continue to send PUBLISH messages at a high frequency, i.e., very frequently. Another possibility is for the presence server to hold back the SIP 200 OK message which must be sent in the SIP protocol as an acknowledgement to the PUBLISH message before the presentity can send a new PUBLISH. But this strategy will trigger a retransmission of the PUBLISH message if the 200 OK reply is held back long enough generating even more traffic. So in this first phase, the inefficiencies relating to the amount of presence signaling can be attributed to the behavior of the individual terminals/presentities running presence applications.
A more attractive solution is to have the presence server (or other network node) send parameters to mandate a certain behavior. For example, the Presence SIMPLE Specification published by the Open Mobile Alliance (OMA) describes an optional parameter called SOURCE-THROTTLE-PUBLISH, which specifies a minimum time between successive PUBLISH messages. But the problem with this parameter is that if it is set to a high value, the accuracy of certain presence attributes will decrease significantly even though the impact on the accuracy of other presence attributes is not significant. In other words, the SOURCE-THROTTLE-PUBLISH parameter does not take into account that different presence attributes might be better served by different presence attribute values. Since there is only one SOURCE-THROTTLE-PUBLISH parameter for all presence attributes, one presence attribute which needs to be “throttled” causes throttling of other presence attributes which do not need throttling. In fact, for some presence attributes, such throttling may reduce the accuracy of the presence attribute information so that it no longer is valuable for the watcher.